In general, metrics have been used to perform such tasks as business process assessment, software design analysis, and software complexity analysis. For example, metrics used for process assessment are typically focused on measuring complexity and tracking process execution times. Because there are limited metrics available that provide reliable tools for assessment of tasks, such as the development of business requirements specifications, the nature of business requirements specifications and other documentary summary data for project applications has made identification of meaningful metrics problematic. Moreover, the challenges of assessing the impacts of project components on the overall progress add to the aforementioned challenges created by documentary summary data. It should be understood, of course, that each project team uses a different developmental approach for defining a requirements specification. For example, some use waterfall, while others use spiral developmental approaches. Regardless of the developmental approach, many project developers use writing methods learned early in their lives. Fundamentally, project developers develop an outline, followed by the content that brings the outline to life. However, at the most fundamental level, the structure of most requirements specifications consists of branches 205a–205f, collectively 205, and leaves 210a–210f, collectively 210, as illustrated in FIG. 2A.
A leaf is, unambiguously, a subsection of a branch. The IEEE 1998-830 standard, a widely used requirements template, provides an example of this structure. For example, section “1.1.1” is a leaf of section “1.1”, assuming that there is no section “1.1.1.1”. Although not shown in FIG. 2A, each section has a title, e.g., a natural language structure would use a function name, an object oriented structure would use an object name, a requirements specification document would use a section title, and an accounting structure would use an account name. Furthermore, each branch 205 and leaf 210 may also include content, such as text, numbers, images, etc., that define the specification document, accounting ledger, software program, or other document, for example.
Consequently, project managers tasked with managing a requirements specification, as previously stated, may lack reliable methods, beyond raw experience, to successfully monitor the progress of a project. As such, the issue of team synergy (where the individual goal-directed actions are focused on the common end result, with a clear understanding of current reality in relation to the end result) and the impacts of teamwork on project progress, regardless of the project nature, has been unmeasurable, thus far. Hence, the inability to measure progress of the project makes judging success extremely difficult.